To help with client code, maybe this signature would work:

It should be basically equivalent with the addition that if there is a type for the props, the createReactNode() implementation can be fully typed.

Slightly more complicated, but something like this:

type AtLeastOne<T> = { [Key in keyof T]: Pick<T, Key> }[keyof T];

export type SingleSpaReactOpts = DomElementGetterOpts & AtLeastOne<{
  createRoot: typeof createRoot;
  hydrateRoot: typeof hydrateRoot;
}> & {
  rootOptions?: RootOptions;
  createReactNode<T = any>(props: T): ReactNode | Promise<ReactNode>
}

Actually matches the requirements on line 27 and makes it possible (in TS) to pass in either createRoot() or hydrateRoot() or both.

For the "both" case, it may be nice to have something like the old renderType property since that allows isomorphic app definitions, but it's probably not required.

good find, updated and added a test

Would it make sense to do something like const configPromise = Promise.resolve(configProp()); to allow both synchronous and asynchronous functions here?

I don't see a reason why a synchronous function would be needed, since you could instead just provide configProp directly. There are no arguments passed to configProp when it's a function, so synchronous function has no use case from what I can tell

It makes sense to remove the dom element assuming it was created during the mount, but at least in OpenMRS, we actually rely on pre-creating the dom nodes that single-spa apps render into. This is mostly to support things like a global layout (we have a global header, a global nav, and a global pop-in called "the workspace"; these things need to "wrap-around" arbitrary MFEs), so removing those domElements on unmount() could result in the app misbehaving when the app is remounted, since the dom element would now be in an arbitrary location.

Good point, I believe that at Canopy they also are not removing the container elements. Also see this line within single-spa-layout, which removes the dom elements at the layout level rather than framework adapter level.

I think the best solution may be to remove the domElement only if it was created by dom-element-getter-helpers, like you suggested. I'll update the code for this.